Network devices frequently employ some kind of forwarding scheme to forward packets to various destinations on a network. Such forwarding schemes commonly include maintaining a forwarding database that has forwarding entries. A forwarding entry will typically have at least a destination address and a corresponding port. Thus, when an incoming packet arrives at a network device having the destination address in its packet header, a lookup of the forwarding database for that destination address will return a port number that tells the network device which port it should use to send the packet back out to the network.
In various types of networks, including ring networks, changes in the topology of the network are, for practical purposes, inevitable. When the topology of a network changes, the forwarding entries maintained in the forwarding database of the network device often become invalid, or at least incorrect. Thus, a typical response to a topology change is to perform an operation that flushes the entries in the forwarding database. In other words, the forwarding entries in the forwarding database are flushed, or deleted, on network devices so that forwarding entries can be relearned for various destination addresses to indicate valid forwarding information. In connection with the flushing of a forwarding database, packet flooding is often used to ensure that packets reach their destination during the time between flushing and relearning of the various forwarding entries. Flooding involves forwarding a copy of a packet on all ports of a network device that are associated with a particular network. So, when a forwarding database is flushed, all of the entries are invalidated and, thus, any incoming packet will trigger a forwarding database (or FDB) lookup that indicates there is no valid entry for the particular destination address associated with the packet. Accordingly, the packet will be flooded out on all ports of the network device associated with the particular network.
One challenge presented by flushing (along with the coinciding flooding and relearning) in response to a network topology change is that flushing forwarding entries can take a long time. For example, it is common for forwarding databases to be organized as a hash table, which adds complexity. Also, some forwarding databases may be very large, with upwards of 500K media access control (MAC) addresses. Not only can flushing and the subsequent relearning take a long time, but it is often the case that many entries are flushed/deleted unnecessarily. For example, a topology change might only involve the failure of a single link in the network and perhaps less than 50 percent of the network topology is affected by the failed link. Unfortunately, flushing is color-blind in that flushing is a one-size-fits-all solution and does not take into account ports and/or links on the network that are unaffected by the topology change.